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(57) Abstract: Methods and systems consistent with the present invention provide a simple and easy-to-use system to make elec- 
tronic payments on the Web. Specifically, methods and systems consistent with the present invention provide anonymity, security 
and accountability. To do so, pre-paid stored value card ("cash card") including a cash card identification number for a predetermined 
amount of money may be purchased at a point of sale. To ensure security, Personal Security Codes are established for a user at a 
server. To use the cash cards, a user may visit a Web merchant, select an item to purchase, and enter the cash card identification 
number and the Personal Security Code to transmit for confirmation to the server. The server subtracts the cost of the item from the 
predetermined amount on the cash card. 
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METHOD AND SYSTEM FOR MAKING ANONYMOUS ELECTRONIC 
PAYMENTS ON THE WORLD WIDE WEB 

RELATED APPLICATIONS 

Provisional U.S. Patent Application No. 60/136,714, entitled "METHOD 
AND SYSTEM FOR MAKING ANONYMOUS ELECTRONIC PAYMENTS ON 
THE WORLD WIDE WEB," filed May 28, 1999, is relied upon and is 
incorporated by reference in its entirety in this application. 

TECHNICAL FIELD OF THE INVENTION 

This invention generally relates to electronic commerce on the World 
Wide Web (the "Web") and, more particularly, to methods and systems for 
making anonymous electronic payments on the Web. 

BACKGROUND OF THE INVENTION 

The Web has evolved into a new commercial environment with 
enormous potential. Fueled by its universal appeal, instant and worldwide 
access, ease of use and low cost of operation, the Web has been the location 
of choice for a surprising number of merchants, vendors and service providers 
alike. 

To realize the full commercial power of the Web, however, it is 
necessary to provide efficient payment mechanisms. With a payment- 
processing infrastructure in place, user (customer) transactions can be 
completely performed on-line without requiring telephone or other forms of 
personal communication. This capability is translated to more efficient 
payment processing, smaller operational costs and, more importantly, a very 
convenient "click-and-pay" method and system for users to use. All of this 
further enhances the Web's potential to bring higher revenue to on-line 
merchants. 

The current payment method of choice for the majority of on-line shops 
is credit cards. Although the use of credit cards is a convenient and 
commercially accepted method of payment, the use of credit cards presents a 
variety of problems for users and merchants alike. First, it is necessary for 
users to obtain a credit-card account. Although this may sound 
straightforward and more or less a universal practice, a problem is that a large 
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part of the user population cannot, or will not, have access to a credit card 
account. Even if the users have credit card accounts, many people still feel 
uncomfortable using their credit cards on-line. This is because the current 
level of trust on the Internet is justifiably very low. Credit cards can easily be 

5 abused, partly because of very relaxed security measures built into credit 
cards, and partly because of the longevity of each credit card account. 
Because of these drawbacks, many users are forced to be extremely cautious 
when giving their credit card information on-line, which many simply will not 
even do. Yet another drawback of using credit cards on-line is the extreme 

10 accountability of credit cards, that is, someone has to track every user's 
payment. In addition, there is a lack of personal privacy which further 
discourages their use over an untrusted and insecure medium such as the 
Internet. As such, whether it is personal choice, justifiable distrust, young 
age, limited income sources, or bad credit, the result is that a lot of revenue is 

15 lost because potential users cannot or will not use their credit cards on-line. 

For merchants too, the current payment process is not an efficient one. 
For example, merchants have to pass an account setup screening process 
similar to the one users have to pass; this is mainly because of the relaxed 
security measures used by credit cards. But in addition to the setup costs, 

20 transaction costs and constant fear of being denied their payments due to 
fraudulent credit card use, merchants have to endure detailed accounting of 
their credit card payments, process payments in a physical manner, initiate 
and maintain communication with a clearing house and, in general, put a lot of 
time and effort into a single transaction. All of this adds up to a very high per- 

25 transaction cost. 

For these reasons, more convenient and cost-efficient payment 
methods have been sought in the past. Examples are electronic cash 
systems (DigiCash, CyberCash), electronic credit card systems (First Virtual, 
SET), telephone-based Internet payment systems (eCHARGE, iBill), and 

30 micropayment systems (Micromint, Millicent). A description of these systems 
follows: CvberCash 
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CyberCash makes software for secure financial exchanges via the 
Internet. CyberCash acts as a gatekeeper linking the Internet to bank 
networks using security based on cryptographic authentication and 
encryption. The user sends CyberCash their credit-card number or bank 
account information, and CyberCash gives them an "electronic wallet" that 
records their transactions over the Internet, encrypts the payment, and sent 1 
it to the merchant. In its instabug model, the user establishes a pre-paid 
instabug account. Buyers hit the "pay" button on the World Wide Web page to 
transfer the funds from their accounts to the merchant's CyberCoin cash 
register. 

DiaiCash 

DigiCash's electronic cash, called eCash, is paperless money that can 
be transferred on the Internet. A computer user withdraws eCash 
electronically from a bank that also subscribes to the system. The digital 
dollars are stored on the user's hard drive and can then be used in a 
transaction with an on-line merchant who accepts eCash. 

eCHARGE 

A user chooses a product at a web page where eCHARGE is available, 
where the freely available eCHARGE software automatically downloads and 
connects the user's computer to a 1-900 number. Charges for the product 
later appear on the monthly local telephone bill. 

E-cash 

E-cash is an instantiation of DigiCash's eCash which is used in 
conjunction with the Mark Twain Bank to allow "authentication" of digital cash 
withdrawals from bank accounts. A software program enables storing the 
withdrawn digital cash on the user's computer hard disk. This stored "cash" 
can then be transferred to a seller's machine. In this system, participants must 
set up a World Currency account provided by the Mark Twain Bank. 

First Virtual Hotdinns 

To use the First Virtual Holdings system the user opens an account 
and is given an Identification (ID) number which is sent to the merchant via e- 
mail. The merchant forwards the e-mail to First Virtual to verify the user's ID 
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number. First Virtual then sends an e-mail message to the user to verify the 
transaction. First Virtual performs the actual transfers over a private off-line 
network using Electronic Data Systems (EDS). 
iBill 

5 Similar to eCHARGE, users can bill one-time charges with iBill's 

Web900 service for access and services directly to their phone bill. The 
Web900 Instruction Page on the merchant's web page tells users how to dial 
an appropriate iBill-maintained 900 telephone number to pay for their 
purchase. When the user dials the 900 number, iBill's automated voice 
10 system reads out a series of numbers. The user then returns to the 

merchant's site and enters these numbers in order to redeem their purchase. 
Millicent 

Millicent, offered by the Digital Equipment corporation, is electronic 
"scrip" in the form of a signed message carrying a serial number and an 
15 expiration date. An authorized broker will buy Millicent scrip from one or more 
merchants at a volume discount and then sell it to users, who will receive and 
then spend it over the Internet. 

NetBill 

NetBill is an alliance between Carnegie Mellon University and Visa, 
20 designed to allow information to be bought and sold over the Internet. Users 
deposit money into a NetBill account which is drawn upon by NetBill when 
purchases are made. 

Smart Cards / Stored Value Cards 

Many prior art schemes involve the use of Smart Cards and Stored 
25 Value cards at a user's computer via a personal swipe or chip reading 
hardware that would read the value of the stored currency on the card's 
embedded computer chip, and transfer purchasing information on-line to an 
accepting merchant. The same system can be applied to credit cards and 
bank-issued debit cards. 
30 SET 

Secure Electronic Transactions is a system designed by MasterCard 
and Visa to allow secure credit card transactions over the Internet. The 
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system requires credit card clearing houses, merchants and users to 
download and install the appropriate software. The credit card information is 
sent encrypted between the user and the merchant and is verified at the 
clearing house, without exposing it to other users of the Internet or to the 
5 merchant himself. Digital signatures authenticate each transaction for future 
auditing. 

The on-line market, therefore, still lacks a simple and easy-to-use 
"click-and-pay" method and system of making electronic payments which 
promotes spur-of-the-moment purchases and payment habits and which 
10 affords anonymity, security and accountability. 

SUMMARY OF THE INVENTION 
The invention is directed to a simple and easy-to-use method and 
system of making electronic payments on the Web that provides anonymity, 
security and accountability. The computer-based method for making 
15 payments on the Web includes the steps of purchasing a pre-paid stored 
value card ("cash card") including a card identification number for a 
predetermined amount of money at a point of sale; logging on to a cash-card 
web server to establish a Personal Security Code (User PIN); logging onto a 
Web merchant; selecting an item to be purchased; and entering the card 
20 identification number and the User PIN, wherein the cost of the item is 
subtracted from the predetermined amount on the cash card. 

BRIEF DESCRIPTION OF THE DRAWINGS 
The accompanying drawings, which are incorporated in and constitute 
a part of this specification, illustrate an implementation of the invention and, 
25 together with the description, serve to explain the advantages and principles 
of the invention. In the drawings, 

Figure 1 is a block diagram of a communication model in accordance 
with an embodiment of the invention for conducting electronic commerce; 

Figure 2 depicts a flow chart of the steps performed when performing a 
30 sale at the point-of-sale (POS) in accordance with methods and systems of 
the present invention; 
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Figure 3 depicts a flow chart of the steps performed when signing up 
an on-line merchant in accordance with methods and systems of the present 
invention; 

Figure 4 is a flow chart of an on-line payment process in accordance 
5 with methods and systems of the present invention; and 

Figure 5 depicts a more detailed diagram of the server depicted in 
Figure 1 . 

DETAILED DESCRIPTION OF THE INVENTION 
The following detailed description of the invention refers to the 

10 accompanying drawings. Although the description includes exemplary 

implementations, other implementations are possible, and changes may be 
made to the implementations described without departing from the spirit and 
scope of the invention. The following detailed description does not limit the 
invention. Instead, the scope of the invention is defined by the appended 

15 claims. Wherever possible, the same reference numbers will be used 

throughout the drawings and the following description to refer to the same or 
like parts. 

In the following sections, the Web browser, architectural overview of 
the invention, lnternetCash SM payment cards, point-of-sale terminals for 
20 distributing the cash cards and a merchant's system are described. In 
addition, a step-by-step payment procedure, the lnternetCash SM payment 
system server architecture and alternate embodiments of methods and 
systems consistent with the present invention are described. 
Overview 

25 The commercial power of the Web has not yet been fully utilized. The 

biggest hurdle has been the availability of an easy to use "click-and-pay" 
computer-based electronic payment method and system. This capability is 
translated to extremely efficient payment processing, smaller operational 
costs and, more importantly, a very convenient "click-and-pay" computer- 

30 based method and system for users to buy goods. All of which further 

enhance the Web's potential to bring higher revenue to on-line merchants. 
Methods and systems consistent with the present invention enable users to 
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buy pre-paid cards at, for example, a convenience store, activate their card by 
selecting a PIN at a specified server, click on a payment button at their site of 
choice, and enter their card number. 

Merchants may also register at the server to open an account and 
5 download the payment software which can be inserted into any web page. 
The computer-based methods and systems consistent with the present 
invention offer user anonymity (via the anonymous purchasing channel), 
accountability, simplicity, speed of use, and the ability to accept 
micropayments. 

10 The invention provides many advantages over the current systems as 

described below by combining electronic verification, which is the minimum 
requirement for on-line payments, with a physical distribution-based pre-paid 
cash card, which is the most convenient way of distributing value. In 
particular, the invention makes electronic verification more efficient, and by 

15 combining electronic verification with pre-paid cash cards, the invention 

provides a convenient and efficient method and system of making electronic 
payments on the Web. The pre-paid cash cards allow payments on the Web 
without requiring an account to be set up and offer anonymity to the users. 
Further, no account-opening or software download procedure is required of 

20 the users. This allows every user to shop, and promotes "spur-of the- 

moment" purchasing behavior, which is a significant advantage for on-line 
shopping. 

The World Wide Web 

The Web is a globally connected network and operates on a 

25 client/server model. A user runs a Web client on a computer called a Web 

browser such as MOSAIC®, NETSCAPE® or INTERNET EXPLORER®. The 
Web client contacts a Web site on a server and requests information or 
resources. The server locates the information and then sends the information 
to the Web browser, which displays the results. 

30 To use the Web, a user makes an Internet connection and launches a 

Web browser. When users surf the Web, they view multimedia home pages 
(Web pages) composed of text, graphics and multimedia content, such as 
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sound and video in a browser. The user may enter a Universal Resource 
Locator (URL) in the browser specifying a location (server) to visit. The user 
may also "click" on a link to forward the user to a new location. 

When a server finds the requested home page, document, or object, 

5 the server sends the information back to the Web browser. 

A Web browser displays information by interpreting the Hypertext 
Markup Language (HTML) used to build home pages. The coding in the 
HTML files tells the browser how to display the text, graphics, links and 
multimedia files on the home page. The HTML file that the browser receives 

10 from the server does not have graphics, sound, multimedia files and other 
resources on it. Instead, the HTML file contains HTML references to those 
graphics and files. The browser may use the references in the HTML file to 
find the files on servers, and display it as a home page in the browser. 

The Web browser typically runs application programs that are written in 

15 JAVA®, a computer language developed by SUN MICROSYSTEMS®. 
JAVA® is a programming language that allows programmers to create 
interactive programs and add multimedia features to home pages. JAVA® is 
object-oriented. Object-oriented programming languages are created by pre- 
existing components, instead of having to write the entire program from 

20 scratch. NETSCAPE is an example of a Web browser capable of running 
JAVA® programs. JAVA® programs that run at the client inside a browser 
are called "applets," such as new stickers which run across Web pages, and 
animations. 

When a user visits a Web site or server that contains JAVA® applets, 
25 each applet is downloaded to the user's computer from the server. Once the 
applet is downloaded it runs automatically. These advances have allowed the 
Internet to become one of the primary places that businesses operate, and 
where billion of dollars of goods and services will be bought and sold every 
year. As businesses use the Internet to market and sell their products, many 
30 people will buy things while at home and from their place of business instead 
of at retail stores. They will use the Internet to browse through catalogs and 
make purchases online. 
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The nature of the Internet, however, is that it is an insecure network. 
As packets travel across the Internet, any user could conceivably examine the 
packets. Because of the Internet's insecure nature, there are potential 
dangers to doing business online. If a user provides credit card information 
5 on the Internet, a third party could steal the credit card number and other 
identifying information. Software engineers have developed schemes to 
transmit confidential information securely to combat ths problem. This is 
known as encryption and decryption. 

Information to be sent needs to be encrypted, that is, altered so that to 
10 third parties the information will look like meaningless garble. The information 
also needs to be decrypted, that is, turned back into the original message by 
-the recipient, and only by the recipient. Many complex systems known as 
"cryptosystems," have been created to allow for this kind of encryption and 
decryption. 

1 5 The heart of understanding how cryptosystems work is to understand 

the concept of "keys." Keys are secret values used by computers in concert 
with complex mathematical formulas to encrypt and decrypt messages. For 
example, if a user encrypts a message with a key, only a user with a matching 
key could decrypt the message. There are two kinds of common encryption 

20 systems: secret-key cryptography, also called symmetric cryptography, and 
public-key cryptography, also called asymmetric cryptography. 

In secret-key cryptography, only one key is used to encrypt and decrypt 
messages. Both the sender and receiver need copies of the same secret key. 
In contrast, public-key cryptography uses two keys (a public key and a private 

25 key). Each user (sender and recipient) has both a public key and a private 
key. The public key is made freely available, while the private key is kept 
secret on the user's computer. The public key can encrypt messages but only 
the private key can decrypt messages that the public key has encrypted. If a 
sender wants to send a message to a recipient, for example, the sender may 

30 encrypt the message with the recipient's public key. But only the recipient, 
with the private key, could decrypt and read the message. The public key 
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could not decrypt the message. An example of public/private-key 
cryptography is the well-known Pretty Good Privacy (PGP) encryption system. 
Architectural Overview 

Methods and systems consistent with the present invention disclose a 
5 communication model, underlying cryptographic algorithms, and system 
requirements that are simple to use while ensuring security, anonymity and 
accountability. 

An advantage of the invention is that it limits the number of interactions 
and communications between participants. Figure 1 shows an embodiment of 

10 a communication model 100 of the invention, also known as "lnternetCash SM ." 

In model 100, lnternetCash SM payment cards are first transferred to a 
physical point-of-sale (POS) terminal 102. A POS may be located in any 
physical store, such as a supermarket, pharmacy, convenient store, or be a 
dispensing terminal similar to an automated teller machine (ATM). At this 

15 point in the preferred embodiment, the cards are inactive which makes the 
value of the cards negligible and thus minimizes the amount of security 
needed for transportation and before any sale at POS terminal 102. Thus, the 
cards can be handled and displayed freely. In fact, products such as camera 
films, batteries, off-the-shelf medications have a more concentrated value 

20 (value per volume) than the cash cards at this point. Because of the low 

value of the cash cards, the cards can be supplied using the same channels 
as other physical products and do not have to be kept in a secure location. 
Activation Procedure 

Before the cards are usable, an activation procedure is performed. In 

25 the preferred embodiment the cards are activated at the time of purchase. In 
the case of a POS at a physical store, activation is performed via on-line 
communication with an on-line banking system server 104, such as 
lnternetCash SM . The on-line communication may be through pre-existing 
means, for example, a card reader with dial-up capabilities or manually via the 

30 telephone. A store-specific personal identification number (PIN) and a store 
identifier (SID) may be used for accountability of activated cards. The SID 
may be used as a store/terminal unique identifier and as a countermeasure 
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against brute force attacks against the PIN. The SID is kept secret and if 
possible it is sent to server 104 upon card activation. Otherwise the store PIN 
is used as an identifier instead. 

Similar to the SID, the PIN prevents impersonation of a store clerk and 
5 false card activation. The larger the number, the lower the risk of it being 
decoded. This is not, however, convenient for the store clerks and may lead 
to typographical errors so the standard credit-card store PIN is used (e.g., 4-8 
digits). Measures such as tracking of repeated failed logins using the PIN 
may be taken to prevent brute force attacks. However, depending on store 

10 requirements the PIN may be the same for all clerks or the PIN may be used 
not for security but simply for indicating the function of card activation. 

Cards may also be purchased from an ATM terminal. The ATM- 
dispensed cards may be activated, for example, by on-line communication 
(described above), or by off-line activation. An example of the off-line 

15 activation may be when a terminal prints out an "activation receipt" 

corresponding to a specific dispensed card. This receipt contains a portion of 
the secret number required for card usage. In either case, the terminal should 
be as secure as a typical ATM terminal because it holds approximately as 
much cash as an ATM (either dispensed cash like an ATM and/or received 

20 cash by the user) and the terminal contains a secret key used either for 
secure on-line communication or for potential generation of the "activation 
receipt." In an alternative embodiment, the dispensed cards may be active at 
time of shipment, so an additional activation is not necessary; such cards 
should be treated as cash as far as liability is concerned. 

25 In addition to the activation procedure at POS terminal 102 or at an 

ATM terminal there may be an additional authorization procedure performed 
by the user. The authorization procedure creates additional security, 
however, a system without the activation procedure may still be secure if the 
manufacturing process of the cards is controlled. First, a user logs into server 

30 104 and is asked for the card number and card secret code. Alternatively, a 
first time user may first need to be authorized by server 104. Server 104 may 
ask the user for the card number and card secret code again. Server 104 
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subsequently accesses the record of the entered card number, verifies the 
card secret code, and that the card has not previously been authorized. 
Server 104 them asks the user to enter a User Personal Security Code 
(UPIN). The UPIN may be between 4 and 8 characters. The UPIN and 
5 associated card number may be stored in a database at server 104, such as 
an ORACLE® database. The activation procedure also affords added 
security to the user, by not allowing a lost card to be spent if the UPIN is not 
available. 

The "click-and-pay" methodology using an lnternetCash SM payment 

10 card will now be explained. First, a user 108 logs in to a web site associated 
with merchant 106 and upon selecting a product/service, clicks, for example, 
a "click-and-pay" button. If user 108 is a first-time user, user 108 may be 
transferred to server 104 to automatically download any required software. If 
the user is not a first-time user, or once the software is downloaded, a window 

15 at the user's computer requesting the InternetCash 81 " payment card number 
may be displayed. Payment information may also be displayed in the window 
for user verification. A merchant number and transaction-specific number 
may be stored at the user's computer for future accountability. 

After entering the InternetCashs" payment card number in the display 

20 window, a payment-specific authentication number (PAN) is sent to server 
104 (or the merchant forwards it) along with the payment data and the card 
number. The PAN is an authentication of the payment information that 
functions as a Message Authentication Code (MAC). To prevent collision 
attacks, current MACs must be 160 bits and can be based on a hash function, 

25 such as the well-known SHA-1 functions. This size should afford sufficient 
protection while 256 bits are projected to provide adequate security for the 
next 25 years. Once received, server 104 may process the transaction. 
Server 104 verifies that the card is active, the PAN has been computed 
correctly, the requested amount is available on the card, subtracts the 

30 payment amount from the card and credits the amount to the merchant's 
account, and returns an acknowledgment to merchant 1 06 as well as user 
108. Alternatively, merchant 106 may forward the acknowledgment from 
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server 104 to user 108. This information may also be stored at user 108's 
computer. If the transaction succeeds, then merchant 1 06 may provide the 
product/service to user 108 using any well-known delivery service, such as 
UPS, or by electronic delivery, such as HTTP, or FTP. 
5 If merchant 106 fails to deliver the product/service once the card has 

been debited, then user 108 may contact server 104 and provide the payment 
data and the transaction-specific number (PAN) previously received during 
the processing of the transaction. Server 104 may determine if user 108's 
card has been charged for this transaction. If the user 108's card has not 

10 been charged, the transaction data is deleted from the database. If the user 
108's card has been charged, then either merchant 106 did not provided the 
requested product/service, or user 108 has not received them or 
acknowledged their receipt. In either case, this is an exception condition, 
which may be handled according to a merchant/lnternetCash SM policy. Se*v>- 

15 104 may also log such events. The click-and-pay methodology is further 
described below with reference to Figure 4. 
Account Cards 

The cards which are used for InternetCashsw for payment on the Web 
will now be described. The first kind of cards which may be used are 

20 magnetic-stripe cards that are dispensable by store clerks. On their backside, 
the cards include: a card ID, a card secret code and directions for using the 
card and potentially a server's telephone number. If present, server 104*s 
telephone number may be used for dialing in for on-line verification; otherwise 
on-line verification is performed via the magnetic stripe, as explained below. 

25 Each card has its own Card ID (CID). The CID is a character 

alphanumeric code comprised of 10 numeric digits and 26 letters. The size of 
the CID is determined as follows: assuming a user base of 1 billion users, 
each user uses two cards a day for a period of 25 years (that is, before the 
CID size needs to be changed), and there are two types of dispensing 

30 systems. This amounts to about 45 bits, or 8.7 (9-10) alphanumeric 

characters. This is based on the calculation that one alphanumeric character 
has 36 different combinations (0-9 and A-Z) thus corresponds to log 2 36 = 5.17 
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binary digits (bits). Therefore 45 bits correspond to 45 + 5.17 « 8.7 
alphanumeric characters. For example, for a CID = 6, there are 
approximately two billion possible CIDs since each alphanumeric character 
represents 1 0+26 = 36 different combinations. With 36 * 2 5 17 , each 
5 alphanumeric character is equivalent to 5.17 bits. Thus 6 alphanumeric 
characters are equivalent to 6*5.17 = 31 .02 bits; and there are 2 31 02 = 
2,177,461 ,402 or approximately 2 billion combinations. 

This CID number does not need to be kept secret and may be visibly 
displayed on the card. The Card Secret Code (CSC), however, must be kept 

10 secret. The CSC is used to provide security for the card. The CSC is a 
character alphanumeric code comprised of the same alphabet of numbers 
and letters as the CID, but it is not displayed on the card, so that only the user 
has this information. The CSC is further described below. 

The directions for using the card include instructions to verify that the 

15 card was indeed activated (an activation receipt may be printed out at POS 
terminal 102) and that the client software at the user 108's computer being 
used at payment time (the payment window) is authorized. The software is 
verified either by downloading it securely from server 1 04, verifying that code 
(e.g., applets) downloaded from a merchant is digitally signed by server 104, 

20 or verifying that the payment window is served from server 104. 

The magnetic-stripe may also contain a Bank Identification Number 
(BIN), the card ID, and server 104's telephone number. There are two types 
of cards that may be used, the type with a scratch-panel and the type without 
a scratch-panel. The scratch-panel type cards use the scratch panels to hide 

25 the CSC. Once a user buys the card the user may scratch off the scratch 
panel to reveal the CSC. Since the card contains hidden information, only 
user 108 knows the number. A warning may be displayed on each card to 
prevent user 108 from buying the card if the panel has been scratched off. 
The cards without scratch-panels are similar to the cards with scratch 

30 panels in that the CSC is typed on the card and covered. The cards without 
scratch-panels may be glued to a paper holder and, thus, the CSC may only 
be seen after user 108 has removed the card from its holder. Alternatively the 
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holder completely encloses the card, so that again the card secret code is not 
exposed unless the cover is ripped opened. A warning may be displayed on 
such cards such that they should not be purchased if the holder has been 
removed. 

5 An alternative to the magnetic-stripe cards is a simple flexible plastic 

card containing the same information as the magnetic-stripe card. With the 
plastic cards, however, a store clerk first dials up server 104 and enters the 
CID to perform on-line activation. Alternatively, these cards are activated at 
shipping time and do not need to be activated at the time of sale. Similarly to 

10 the magnetic-stripe cards, there are two types of plastic cards: the type with 
scratch-panel for protecting the secret code and the type without scratch- 
panel. 

Cards may also be dispensed from an unmanned ATM-style terminal. 
These dispensed cards do not need a magnetic-stripe or a scratch-panel 
15 because there is no human involvement and, as such, there is no danger of 
stealing the CSC code. Instead, the CSC is calculated and given to the user 
by the terminal. This calculation is performed using a terminal-specific secret 
key (TSK) and a cryptographic one-way or hash function. The TSK is further 
described below. 

20 The CSC is either printed on the card at the time of sale, on a separate 

"receipt" paper, or is simply shown to user 108 who is prompted to write the 
code on the card. The dispensed cards may be made of materials, such as 
paper, plastic, or a magnetic-stripes. The paper cards may be printed on the 
fly by the terminal since most ATM machines have a printer. This requires no 

25 dispensing system. The paper cards contain the CID and directions for 
usage. The ATM may print the card and include the CSC on the card. 

The flexible plastic card may or may not require some type of low- 
security dispensing mechanism, but provides a "tangible" material for user 
108. Finally, the magnetic-stripe cards allow reloading at any POS 102. The 

30 magnetic-stripe cards, however, are more expensive and may require a 

method of securely dispensing to prevent theft. Additionally, the magnetic- 
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stripe cards may contain server 104's telephone number and/or the BIN and 
CID numbers. 

In an alternative embodiment, pre-activated cards may be dispensed 
from separate canisters within an ATM machine. ATM machines have 
5 separate canisters that hold products, such as stamps, or checks. These 

ATMs also include software that prompts user 108 and subtracts funds from a 
user 108's account when user 108 purchases items from the canister. Cash 
cards may be dispensed from ATM machines using these canisters. 
POS Sale 

10 Figure 2 depicts a flow chart of the steps performed when performing a 

sale at the POS Terminal 102 consistent with methods and systems of the 
present invention. As discussed above, there are two forms of sales. Sales 
at a store using a POS terminal 102 (manned sale) and sales at an ATM 
terminal (unmanned sale). With a manned sale, the store clerk's role is to 

15 activate the card. 

First, a secure connection to server 104 is established (step 202). 
Typically, this is a dial-up session but an Internet connection is also possible 
depending on the facilities available at the POS Terminal 102. If a magnetic 
card is used, then the dial-up connection may be performed by using an 

20 existing card-reader with dial-up capabilities used for credit-card 

authentication. In this case the BIN number and/or the telephone number of 
server 104 is encoded on the magnetic-stripe so all that is required from the 
clerk is to simply slide the card through the reader and select the appropriate 
button for card activation. 

25 Once connected, the store clerk may input a CID and a store-specific 

PIN that are then transmitted to server 104 (step 204). The CID may be 
encoded on the magnetic-stripe so this is sent automatically to server 104. 
The clerk may then input a store-specific PIN to activate the card. 

Alternatively, the cash cards may be activated in batch form, (e.g., five 

30 or ten) such that each card need not be activated as it is sold. In a batch 
mode, the clerk inputs the batch number of the cards, which identifies that 
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particular batch. If the dial-up device supports encryption and authentication, 
the batch mode may be utilized over this link. 

Next, server 104 may process the transaction (step 206). During 
processing, server 104 activates the particular CID or card. The store's PIN 
may be saved together with the activation record (CID or batch and 
timestamp). Merchant 106 may be charged immediately or periodically, such 
as once a day. In addition, an acknowledgment may also be returned as part 
of processing the transaction and a receipt may also be printed for user 108. 

Alternatively, the POS method may be performed by an unmanned 
sale. Depending on the payment scenario, either a secret key inside POS 
terminal 102 needs to be secured or the POS terminal 102 may have a secure 
dispensing canister (in the case where the card is paid by withdrawing cash 
directly from a user 108's bank account). In the case where user 108 pays by 
cash terminal 102 should also accept cash. For example, ATM machines 
require both a secured secret key and the ability to store cash and also 
include secure dispensing canisters. 

There are several scenarios for the unmanned sale, depending on both 
the POS terminal 102 and type of card used. For example, in an ATM- 
bundled sale, a bank ATM may provide user 108 an additional choice of 
"Buying an InternetCashsw payment card." If user 108 desires to purchase an 
InternetCashs" payment card, user 108 may select desired values, such as 
ten dollars or one hundred dollars. The ATM withdraws an appropriate 
amount from user 108's bank account and prints the card including the CID, 
CSC, directions for use and a transaction receipt. Alternatively, a set of 
blank cards may be located next to an ATM and user 108 may be required to 
write (with an attached pen) the CID and secret code on each card. This 
provides for a more "tangible" card. The ATM may then notify server 104 that 
a specific card has been sold. Alternatively, the ATM may notify server 
104 at a later time, such as once every night for all cards sold that day. The 
ATM may then further process a list of available CIDs and a secret key which 
can be used to compute the card's secret code. The CIDs are unique in that 
they do not require explicit activation, and are activated in advance. Security 
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may also be provided by a controlled generation of the secret codes, based 
on the ATM's secret key. The ATM secret key (TSK) is specific to each ATM 
used to compute the CSC. The secret key is inserted securely (for example, 
by designated personnel, or via a secure channel) and is generated by server 
5 104 based on a master key and a unique identifier, such as the exact location 
and bank name of a particular ATM. In an alternative embodiment, pre- 
activated cash cards are provided in a secure dispensing canister, and after 
collecting money from user 108 may dispense the cards similar to how cash is 
dispensed. In this case, cash cards are formatted to a size similar to a paper 

10 bill and include a scratch panel similar to the cash cards sold by a store clerk. 
In an alternative embodiment, a cash-terminal sale accepts cash. 
Instead of accessing a user 1 08's bank account as in the ATM terminals, the 
cash-accepting terminals accept cash. A cash-accepting machine only needs 
a printer and does not need a dispjay. 

1 5 Additionally , a cash accepting machine may be used to dispense pre- 

activated cards stored in a secure canister. This machine does not need 
specific additions, with the only requirement being secure transfer of cash 
cards and positioning them into the canister. 
CID Generators 

20 Examples of CID generators, secret and master keys, and terminal 

identifiers will now be described. 

(1 ) CID: In the case of point-code tracking the CID may be a 

concatenation of binary digit "1" (denoting point-code tracking) and a terminal 

unique identifier (TID) (8 decimal digits) to an ever-increasing serial number. 
25 Point-code tracking is defined as allowing tracing in dispensing terminals 

using the CID and by generating secret code on-the-fly by unmanned 

terminals. 

In the example where the CID is the concatenation of the TID and a 
serial number, the CID discloses the TID and thus the dispensing terminal. 
30 The TID number is based on an assumption that there are 100 million 
terminals. These numbers are converted to binary, concatenated and 
converted to alphanumeric characters (base 36). 
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Thus, assuming there are 100 million dispensing points with each 
dispensing point dispensing a maximum of 2,500 cards per POS per day for 
two types of dispensing systems (point-code tracking and user-based) over a 
25 years system life, this amounts to 51 bits, or 10 alphanumeric characters. 

5 Thus the number of cards over 25 years = 100,000,000 (dispensing points) * 
2,500 (cares per day per dispensing points) * 365 (days in a year) * 25 (years) 
« 2,281,250,000,000,000 * 2 S1 . Thus the number of cards over the next 25 
years can be represented with 51 bits, which amount to 51 + 5.17 = 9.86 
alphanumeric characters. 

10 Cards and CIDs may be generated inside a cash card terminal by 

using a pseudorandom or sequential algorithm. The same space on the cards 
should not used for both point-code tracking and regular cards. For example, 
the regular CIDs may start with a binary digit "0." The batch cards may also 
contain a batch number which can optionally be printed on the cards. The 

15 batch cards may be packed in batches and/or be activated in batches, either 
through a web interface within server 104 or through a phone interface. 

(2) Internet Master Key (IMK): The IMK is created in a 
cryptographically secure way, and may contain over 160 bits. The IMK may 
contain random bits that are processed by a cryptographic function, such as a 

20 one-way hash function. These random bits may be created as a combination 
of inputs, including the lnternetCash SM administrator's keystroke, mouse 
movements, hard-drive speed variations, operating system state, time 
variations between hardware clocks, or other hardware sources of 
randomness, such as oscillators, or lava lamps. 

25 A brute force attack against the IMK could allow total manufacturing of 

cards. In this context, a "brute force attack" is the case where the attacker 
tries all possible values of a secret key, in this case the IMK, until the correct 
value is found; thus, at least 128 bits must be used, and preferably 256 bits. 
The IMK may expire at any time and cards manufactured after that point 

30 should use a new key. It is preferable that the IMK be refreshed at regular 

intervals (for example, annually) and be stored in a tamper-resistant hardware 
cryptographic device. 
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(3) Terminal Secret Key (TSK). CSC = H(TSK, CID), where H is a 
cryptographic hash function. TSK may in turn be calculated using an IMK and 
the TID in combination with a cryptographic one-way or hash function; for 
example TSK = H(INK, TID), where H is a cryptographic hash function. This 

5 is generated by the IMK as follows: TSK=H(IMK, TID), where H is a one-way 
hash function or a block cipher (in which case IMK is the key) whose output is 
casted (truncated) to the required size for TSK. 

Brute force attacks against the TSK key could allow manufacturing of 
cards for a particular terminal. Since the terminal can be "black marked," this 

10 type of attack may not be very costly. In other words, if the terminal's key is 
lost, the terminal identifier can be marked as invalid starting from the time of 
security breach and ending at the time where the terminal is repaired, and all 
cards that are manufactured by this terminal in this time interval are also 
deemed as invalid. It is preferable that an 80-128 bit key be used, but if 

15 convenience dictates, a standard 56-bit DES key may be used. 

(4) Card Secret Code (CSC). The CSC key is used to generate the 
Payment Authentication Number (PAM). For a CSC = 10, the card is secured 
with a secret key of approximately 10*5.17 = 51 bits. Brute force attacks 
require either querying the server 104 for each attempt or verifying against a 

20 payment, which is much more efficient. However, only one card is 
impersonated if such an attempt succeeds, so we need to solve for: 
Cost of brute force > value of card. 
The CSC is generated using the TSK as follows: 
CSC=H(TSK, card ID), 
25 where H is either a one-way hash function or a block cipher (in which 

case TSK is the used key) casted (truncated) to the required size for CSC 
(11-16 alphanumeric digits). In sum, server 104 may generate the CSC given 
the CID and IMK. That is, from the CID, server 104 obtains the terminal 
identifier TID and computes TSK (TSK = H(IMK, TID)) and, finally, the CSC 
30 (CSC = H(TSK,CID)). Server 104 may now verify that the card has been 
generated ("activated") by a designated terminal. 
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For non-point-code tracking cards, the CSC can be calculated directly 
from the IMK and the CID: 
CSC = H(IMK.CID). 

It is expected that 56 bits are enough for small card values (<$100) for 
5 a 5-year period (a goal is to prevent users from cracking cards at their 

desktops). Eighty bits are enough even for large card values. It should be 
reminded that brute force attacks require theft of payment, which is 
transmitted over SSL; "SSL" refers to the Secure Sockets Layer protocol 
which is being utilized for encrypting and authenticating data that is sent over 
10 the Internet or other insecure or public lines; SSL is a de-facto standard used 
by Netscape Communicator ®, Internet Explorer ®, and other commercial 
browsers. 

(5) A PAN used for authentication may be calculated as follows: 
PAN=H(CSC, UPIN, Payment Info), 

15 where H is a hash function (or a block cipher, in which case 

CSC and UPIN are used as key. 
On Line Registration 

Figure 3 depicts a flow chart of the steps performed when signing up 
an on-line merchant 106 and user 108. First, on-line merchant 106 obtains a 

20 registration number and an account at server 104 (step 302). To register, on- 
line merchant 106 may log onto a web site and fill out an on-line application. 
Alternatively, on-line merchant 106 may communicate with an lnternetCash SM 
account representative. Depending upon the type of reimbursement on-line 
merchant 106 chooses, the application is approved either automatically or 

25 after appropriate background credit checks. Once the account is opened and 
authorized, a merchant identification number is assigned to merchant 106 
which may be different from the account number for security purposes. 

Next, server 104 sends (or the merchant may download) a signed, 
"payment program" to merchant 106 (step 304). This program may be, for 

30 example, a JAVA® applet that can then be incorporated inside any web page 
associated with merchant 1 04, or a program that includes sample web pages 
and other processing code that interfaces with merchant 104 associated with 
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a back-end system. The code may be signed by server 104 and based on a 
public key. The public key is certified by a Certification Authority (CA), such 
as VERISIGN. The code comes complete with everything that is needed to 
process a payment, such as plug-ins for merchant 106 to add payment 

5 information and code for displaying the payment information. The plug-ins are 
for information such as dollar amount of purchase, description of product(s) 
sold, date and time of product sold and an empty "comments" section for 
additional information (this acts as a "memo" on a personal check). Any code 
sent to user 108's computer during a purchase, includes programs for 

10 displaying the payment information, including merchant 106's identifying 

information, programs for user 108 to enter additional comments, programs 
asking user 108 to enter their lnternetCash SM payment card number and 
UPIN, and programs allowing the signing (or authenticating) of the payment 
information using the card's secret code and UPIN as the key. 

15 The payment window code is used to send the payment information 

and a PAN to server 104 potentially through redirection to the merchant, and 
waits for confirmation from server 104, including the categorized payment 
information. Server 104 processes the transaction received from payment 
window code at merchant 106 and sends a confirmation of payment to the 

20 payment code window, either directly or through merchant 106. 

Additionally or alternatively, the payment program may be personalized 
for each merchant 106. Merchant 106's identifying information may be 
displayed in the program as a headline, ticker, or border of the payment 
window, and may be included in the lnternetCash SM generated signature. 

25 This way, only authorized merchants 106 can use the payment program, and 
provides for greater accountability within model 100. 

The instantiation of the merchant-specific program signing can be 
performed by the addition of the merchant identifying information into the 
payment program, before server 104 signs the confirmation. In addition, the 

30 merchant-specific program signing enables server 104 to outsource the 
signature authorization and certification to an external CA. 
On Line Purchase Method 
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Figure 4 depicts the steps performed when a user 108 uses the on-line 
payment process. First, user 108 logs into a Web site associated with 
merchant 106 and selects the goods/services to be purchased (step 402). If 
user 108 is a first-time user, user 108 may be forwarded to server 104 for an 
5 automated downloading process of the required software (e.g., payment 
window code). If user 108 is not a first-time user, or once the software is 
downloaded, a window at user 108*s computer requesting an IntemetCashs" 
payment card number is displayed (step 404). In response to user 108's 
selection of goods to purchase, the merchant payment program provides the 

10 product information, the merchant's identification number, a payment serial 
number, the payment amount and, optionally, a transaction time stamp to the 
payment code window on user 108's computer (step 406). The information is 
displayed to user 108 either through the code (e.g., JAVA® applet), as a 
redirection from server 104, or through a client resident program (e.g., a 

15 browser plug-in). Once the merchant software transmits the information to 
user 1 08, the merchant payment program waits for a payment 
acknowledgment from server 1 04. 

After the optional verification of the InternetCashsw signature by the 
payment code window, user 108 verifies the payment information, optionally 

20 adds any comments in the comment area and enters the lnternetCash SM 

payment card number and UPIN (step 408). Either the payment code window 
or server 104 may compute the PAN based on the CSC and UPIN. 
Additionally, the computed information may be locally saved at user 108's 
computer file indexed by the merchant's identification number and transaction 

25 number. Once computed, the payment information and PAN are then sent to 
server 104 (step 410). Alternatively, user 108 may transmit the information to 
merchant 106, who may forward the payment information to server 104 (step 
410). 

Next server 104 confirms the transaction (step 412). During 
30 confirmation, server 104 may access the card repository file indexed by CID, 
verify the card validity, obtain or recompute the CSC and UPIN, verify fund 
availability, subtract funds from the card account, and credit merchant 106's 
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account. If the payment information is not correct, user 108 may be given the 
option to re-enter the data, if the card has not been authorized on-line, (e.g., 
a UPIN has not already been selected), then user 108 may be redirected to 
an on-iine activation page located at server 104, to select a UPIN, before the 
5 payment transaction proceeds. Finally, if the funds remaining on the card are 
not sufficient to cover the cost of goods to be sold, user 108 may be given the 
option of using an additional card for the remaining amount. 

Upon successful completion of step 412, server 104 returns an 
acknowledgment to merchant 106 and user 108, indexed by a merchant 

10 number and a transaction number and a transaction time stamp (step 414). 
The signature may be based on an IMK. The merchant payment software 
and the payment code window saves this information in a local file. However, 
only the merchant software needs to verify the signature's validity before 
sending the product(s) to user 108 (step 416). 

15 The verification of the lnternetCash SM payment card signature on the 

payment information and PAN at merchant 106 computer are performed 
automatically by the payment software. This returns an "accept" code to the 
merchant, who then may initiate the shipment process. 

Disputes over payments and deliveries may be handled based on all 

20 saved information merchant 106 and user 108. If, for example, merchant 106 
did not send the paid-for products, then user 108 may provide the payment 
information and acknowledgment to server 104 to verify their validity. 
System Design 

Figure 5 depicts a system 500 running on a reliable and secure 
25 platform. Server 104 may be, for example, an NT® or Unix®-based server on 
a SUN® workstation. All cryptographic operations are performed inside 
server 104. Server 104 is connected to a database 502 that contains a list of 
all issued cards, separated as active and inactive, and all transactions 
performed by each card. Database 502 may be an encrypted and signed 
30 24x7 database. Cards in server 104 may be indexed by the CID. Each card 
entry contains the manufacturing date and time, the date, time and location of 
activation, the total value and the remaining value. A modem pool 504 may 
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also be connected to server 104 to accept dial-up connections from POS's. 
Front end web server 506 contains a firewall and an HTTP front end 508 to 
provide security to server 104. The web server 506 serves as an intermediary 
between server 104 and network 510. 
Conclusion 

The invention as described above is a novel solution which can be 
used by any user without requiring specific knowledge or even software 
installation. Methods and systems consistent with the present invention 
require no user accounts, provide anonymity and simplicity of use, and are 
nevertheless secure and accountable as any cash system should be. 

As explained, methods and systems consistent with the present 
invention overcome the shortcomings of existing financial transactional 
systems by providing users the ability to spend on-line easily, safely, 
anonymously, in small or large increments with no personal attachment to 
Internet service providers, billing, credit card, or banking institutions. 

The foregoing description of an implementation of the invention has 
been presented for purposes of illustration and description. It is not 
exhaustive and does not limit the invention to the precise form disclosed. 
Modifications and variations are possible in light of the above teachings or 
may be acquired from practicing of the invention. For example, the described 
implementation includes software but the present invention may be 
implemented as a combination of hardware and software or in hardware 
alone. The invention may be implemented with both object-oriented and non- 
object-oriented programming systems. 

Attached is an appendix of exemplary number sizes for the various 

keys. 
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Appendix 



The quantities defined here are cryptographic key sizes within the 
system of the invention, as well as some assumptions regarding the size of 
the user base and POS terminals. 



Quantity 


Size 


oiu (Card ID) 


9-10 alphanumeric chars 


ObC (card becret Code) 


11-16 alphanumeric chars 


1 alphanumeric character (0-9, A-Z) 


=5.17 bits = 1.55 decimal 


1 alphanumeric character (0-9, A-Z, except 
1.0,Q,Z) 


=5 bits = 1.5 decimal 


SID (Store/terminal ID) 


20 decimal digits 


PIN (Store/clerk PIN) 


6-8 decimal digits 


1 decimal digit 


= 3.3 bits 


TID (Terminal ID) H 


8 decimal digits 


IMK (InternetCash^ symmetric Master 
Key) 


128-256 bits 


TSK (ATM/Cash Terminal symmetric 
Secret Key) 


56-128 bits 






PAN (Payment Authentication Number) 


160-256 bits 


IPK (lnternetCash SM public key) 


1024-4096 bits 


UPIN (User PIN) 


4-8 alphanumeric digits 
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WE CLAIM : 

1 . A computer-based method for making anonymous payments in 
a network, comprising the steps of: 

purchasing a cash card including a card identification number for a 
5 predetermined amount of money at a point of sale terminal; 

logging on a Web site associated with a merchant from a user's 
computer; 

selecting an item to be purchased; and 
entering the cash card identification number, 
1 ° wherein the cost of the item is subtracted from an account associated 

with the cash card. 

2. The computer-based method for making payments in a network 
of claim 1 , wherein the step of entering the cash card identification number 
further comprises the step of entering a personal security code in a server, 

15 wherein the server maintains a record of the personal security code. 

3. The computer-based method for making payments in a network 
of claim 2, further comprising the step of verifying that the personal security 
code is associated with the cash card. 

4. The computer-based method for making payments in a network 
20 of claim 3, further comprising the step of entering the cash card identification 

number and the personal security code to obtain the balance remaining in an 
account associated with the cash card. 

5. The computer-based method for making payments in a network 
of claim 3, further comprising the step of entering the cash card identification 

25 number and the personal security code to obtain a list of the transactions 
performed in an account associated with the cash card. 

6. The computer-based method for making payments in a network 
of claim 1 , further comprising the step of entering multiple the cash card 
identification numbers and personal security codes for performing a single 

30 purchase. 

7. The computer-based method for making payments in a network 
of claim 6, further comprising the step of displaying an amount of a purchase 
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remaining after each cash card identification number and personal security 
code is entered and an amount available in an account associated with the 
cash card. 

8. The computer-based method for making payments in a network 
5 as in claim 1, wherein the step of purchasing a cash card further comprises 

the step of activating the cash card by transmitting a store-specific personal 
identification number to a cash card server. 

9. The computer-based method for making payments in a network 
as in claim 1 , wherein the step of purchasing a cash card further comprises 

10 the step of activating the cash card by transmitting a fixed personal 

identification number to a cash card server to signal that the cash card is to be 
activated. 

10. The computer-based method for making payments in a network 
as in claim 1 , wherein activating the cash card further comprises the step of 

15 transmitting a predetermined amount of money to a cash card server. 

1 1 . The computer-based method for making payments in a network 
as in claim 1 , wherein the step of purchasing a cash card further comprises 
the steps of: 

activating the cash card by performing off-line activation; and 
20 printing out an activation receipt corresponding to the cash card and 

including a secret number. 

12. The computer-based method for making payments in a network 
as in claim 1 , wherein the cost of the item plus an additional transaction fee is 
subtracted from an account associated with the cash card. 

25 13. The computer-based method for making payments in a network 

as in claim 1 , further comprising the step of storing payment information on a 
user's computer, wherein the payment information includes a merchant 
number and a transaction number. 

14. The computer-based method for making payments in a network 

30 as in claim 1 , further comprising the step of entering a payment-specific 
authentication number. 
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15. The computer-based method for making payments in a network 
as in claim 1 , further comprising the steps of: 

storing on a user's computer the cash card identification number; and 
receiving a selection for the cash card identification number from a list 
5 of saved cash card identification numbers. 

16. The computer-based method for making payments in a network 
as in claim 1 , further comprising the step of verifying that the cash card is 
active and that the requested purchasing amount is available. 

1 7. The computer-based method for making payments in a network 
10 as in claim 1 , further comprising the step of crediting an amount associated 

with a purchase to an account associated with the merchant. 

18. The computer-based method for making payments in a network 
as in claim 1 , further comprising the step of crediting a purchasing amount 
minus a fee to an account associated with the merchant, wherein the fee is 

15 based on the purchase amount or a fixed fee. 

19. The computer-based method for making payments in a network 
as in claim 1 , further comprising the step of sending a purchasing 
acknowledgment to the merchant and the user. 

20. The computer-based method for making payments in a network 
20 as in claim 1 , wherein the cash card contains a magnetic-stripe. 

21 . The computer-based method for making payments in a network 
as in claim 20, wherein the magnetic-stripe comprises a telephone number of 
a cash card server, a character alphanumeric code card identification, a 
character alphanumeric code card secret code and directions for using the 

25 cash card. 

22. The computer-based method for making payments in a network 
as in claim 20, wherein the magnetic-stripe comprises an encoded cash card 
number, wherein the cash card number includes a cash card identification 
number, a bank identification number (BIN), a Lin mod-10 authentication digit 

30 and an expiration date, such that the BIN is used to route the magnetic stripe 
information to a central server for on-line verification. 
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23. The computer-based method for making payments in a network 
as in claim 20, wherein the magnetic stripe contains a telephone number 
associated with a cash card server for on-line verification, a card batch 
number and directions for using the cash card. 
5 24. The computer-based method for making payments in a network 

as in claim 1 , wherein the cash card is of the scratch-panel type or glued to a 
paper holder, or a flexible plastic cash card. 

25. The computer-based method for making payments in a network 
as in claim 24, wherein the cash card secret code is hidden in a scratch-panel 

10 and is revealed by scratching off the scratch-panel. 

26. The computer-based method for making payments in a network 
as in claim 24, wherein the cash card secret code is covered by the paper 
holder and is revealed by removing the cash card from the paper holder. 

27. The computer-based method for making payments in a network 
15 as in claim 1 , wherein the cash card is dispensed from an automated teller 

machine (ATM). 

28. The computer-based method for making payments in a network 
as in claim 27, wherein the ATM contains a Terminal Secret Code to compute 
a cash card secret code from a card alphanumeric code printed on the cash 

20 card. 

29. The computer-based method for making payments in a network 
as in claim 28, further comprising the steps of: 

computing the Terminal Secret Code by a cash card server using a 
master key; and 

25 transmitting the Terminal Secret Code using a secure channel to the 

ATM. 

30. The computer-based method for making payments in a network 
as in claim 29, wherein the Terminal Secret Code is stored in tamper-resistant 
hardware within the ATM. 

30 31 . The computer-based method for making payments in a network 

as in claim 30, further comprising the step of providing the cash card secret 
code to the user. 
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32. The computer-based method for making payments in a network 
as in claim 29, wherein the cash card is a paper cash card. 

33. A computer-based method for activating a cash card for making 
payments in a network using a POS terminal, the cash card includes a card 

5 identification number and the terminal is assigned an identification number, 
the computer-based method comprising the steps of: 

establishing a secure connection to a cash card server; 
inputting the cash card identification number and a terminal 
identification number; and 
10 activating the cash card identification number. 

34. The computer-based method for activating a cash card of claim 

33, further comprising the step of storing the identification numbers with an 
activation record. 

35. The computer-based method for activating a cash card of claim 
15 34, wherein the activation record includes the cash card identification number 

and a timestamp. 

36. The computer-based method for activating a cash card of claim 

34, further comprising the step of encrypting the identification numbers with 
the activation record. 

20 37. The computer-based method for activating a cash card of claim 

34, further comprising the step of transmitting an acknowledgment notification 
to the user once the cash card has been activated. 

38. The computer-based method for activating a cash card of claim 
33, wherein the connection is an Internet connection. 
25 39. A computer-based method for purchasing a cash card for 

making payments in a network from an automated teller machine (ATM), the 
cash card includes a cash card identification number, a secret code and 
directions for use, the computer-based method comprising the steps of: 

providing an ATM user a choice of buying the cash card from the ATM 
30 machine; 

selecting a value of the cash c<rr ;i to be purchased; 
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withdrawing an appropriate amount of money from an account 
associated with the ATM user; 

printing the cash card, including the cash card identification number, 
the secret code, the directions for use and a transaction receipt; and 

notifying a cash card server that a cash card has been sold. 

40. The computer-based method for purchasing a cash card for 
making purchases of claim 39, wherein the cash card server is notified at a 
later time for the purchase. 

41 . The computer-based method for purchasing a cash card for 
making purchases of claim 39, wherein the ATM cash card is pre-printed and 
stored inside the ATM. 

42. A computer-based method of opening and registering an on-line 
vendor account with a cash card server having a web site, comprising the 
steps of: 

logging onto the cash card server's web site; 

receiving an application from the vendor to accept cash card payments; 
approving the application; 

opening an account for the vendor if the application if approved; and 
assigning a vendor identification number for the vendor. 

43. The computer-based method of opening and registering an on- 
line vendor account with a cash card server of claim 42, further comprising the 
step of approving the application after appropriate background checks. 

44. The computer-based method of opening and registering an on- 
line vendor account with a cash card server of claim 42, further comprising the 
steps of: 

entering a user's cash card number and a personal security code; 
adding any comment to payment information; and 
computing a payment authentication number specific to the payment 
information and user supplied data. 

45. The computer-based method of on-line payment of claim 44, 
further comprising the steps of: 
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sending the user's signature, the payment information and the cash 
card number to a cash card server; 

verifying the payment information from the user; 
verifying a payment acknowledgment from the cash card server on a 
5 payment applet; and 

notifying the user of the finality of the purchase. 

46. The computer-based method of opening and registering an on- 
line vendor account with a cash card server of claim 42, wherein the 
approving step further comprises the step of automatically approving the 

10 application. 

47. The computer-based method of opening and registering an on- 
line vendor account with ? cash card server of claim 42, further comprising the 
step of sending a secret key to the vendor once the application is approved. 

48. The computer-based method of opening and registering an on- 
15 line vendor account with a cash card server of claim 42, wherein the secret 

key is generated by the cash card server from a master key. 

49. The computer-based method of opening and registering an on- 
line vendor account with a cash card server of claim 42, further comprising the 
step of supplying a signed payment program to the vendor for accepting on- 

20 line payments. 

50. The computer-based method of opening and registering an on- 
line vendor account with a cash card server of claim 49, wherein the payment 
program includes identification information associated with the vendor. 

51 . The computer-based method of opening and registering an on- 
25 line vendor account with a cash card server of claim 49, wherein the signed 

payment program is a Java applet. 

52. The computer-based method of opening and registering an on- 
line vendor account with a cash card server of claim 49, wherein the signed 
payment program is a program specific to a back-end system associated with 

30 the vendor. 

53. The computer-based method of opening and registering an on- 
line vendor account with a cash card server of claim 49, wherein the signature 
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on the signed payment program is calculated using a cash card server's 
public key. 

54. The computer-based method of opening and registering an on- 
line vendor account with a cash card server of claim 49, further comprising the 

5 step of transmitting an applet to the user from the cash card server, wherein 
the applet enabled the user to authenticate the payment information. 

55. The computer-based method of opening and registering an on- 
line vendor account with a cash card server of claim 54, wherein the plug-in 
areas include an area for a dollar amount of purchase, an area for description 

10 of a product sold, an area for the date and time of product sold and an area 
for comments for additional information. 

56. The computer-based method of opening and registering an on- 
line vendor account with a cash card server of claim 55, further comprising the 
step of authenticating the payment information with the secret code 

15 associated with the cash card. 

57. The computer-based method of opening and registering an on- 
line vendor account with a cash card server of claim 54, further comprising the 
steps of: 

displaying the payment information in a display window, including the 
20 vendor's identifying information; 

providing an area inside the applet for the user to enter additional 
comments; 

requesting the user to enter the cash card number inside the applet; 
authenticating the payment information using a payment authentication 
25 number and the applet; and 

sending the payment information and payment authentication number 
to the cash card server. 

58. The computer-based method of opening and an on-line vendor 
account with a cash card server of claim 42, wherein after the user is 

30 registering to the server, the computer-based method further comprises the 
steps of: 
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displaying the payment information, including the vendor's identifying 
information; 

providing an area in the page displayed by the PAN server for the user 
to enter additional comments; 

requesting the user to enter the cash card number in an area inside the 
page displayed by the PAN server; 

having the PAN server authenticate the payment information using a 
payment authentication number; and 

sending the payment information and payment authentication number 
to the cash card server. 

59. The computer-based method of opening and registering an on- 
line vendor account with a cash card server of claim 58, further comprising the 
step of sending a confirmation of a payment to the user. 

60. A computer-based method of on-line payment, comprising the 
steps of: 

logging onto a vendor's Web site, wherein the Web site includes a 
payment software for providing product information, a vendor identification 
number, a payment serial number, a payment amount and a transaction time 
stamp to the payment software; 

selecting goods/services for a user to purchase; 

displaying purchasing information by the user; and 

receiving a payment acknowledgment from a cash card server. 

61 . The computer-based method of on-line payment of claim 60, 
further comprising the step of redirecting the user to a PAN server to display 
purchasing information. 

62. The computer-based method of on-line payment of claim 60, 
further comprising the step of transmitting an applet to the user to display 
purchasing information. 

63. The computer-based method of on-line payment of claim 62, 
further comprising the steps of: 

verifying payment information from the user; 

adding comments to the payment information; and 
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entering a cash card number to finalize the payment of the purchase. 

64. The computer-based method of on-line payment of claim 63, 
further comprising the steps of: 

computing a payment authentication number based on a cash card 
5 secret code by the applet; and 

saving the purchasing information and the payment information locally 
into a file indexed by the vendor identification number and a transaction 
number. 

65. The computer-based method of on-line payment of claim 61, further 
10 comprising the step of sending the payment information and the PAN by an 

applet to the cash card server. 

66. The computer-based method of on-line payment of claim 65, 
further comprising the step of waiting for confirmation by the applet. 

67. The computer-based method of on-line payment of claim 66, 
15 further comprising the following steps performed by the cash card server: 

accessing a cash card repository file indexed by cash card ID; 
obtaining the cash card secret code; 
verifying fund availability; 
subtracting funds from a user's account; and 
20 crediting a vendor's account. 

68. The computer-based method of on-line payment of claim 67, 
further comprising the following steps being performed by the cash card 
server: 

returning a signed payment acknowledgment to the vendor and the 
25 user, indexed by the vendor identification number and the transaction number; 
and 

saving information in a file at both the user-residing applet and the 
vendor payment software. 

69. The computer-based method of on-line payment of claim 68, 
30 further comprising the steps of: 

verifying the signature's validity on the signed payment 
acknowledgment by the vendor payment software; and 
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sending the purchased goods/services to the user. 

70. A method for providing a cash card for a user to make 
purchases in a network anonymously, wherein the cash card is associated 
with an account containing a predetermined amount of money, comprising the 

5 steps, executed in a data processing system, of: 
activating the cash card at a point of sale; 

authorizing the cash card such that an account associated with the 
cash card contains funds to make purchases with; and 

providing the cash card to a user, wherein a cash card secret code and 
10 a cash card identification we associated with the cash card. 

71 . The method of claim 70, wherein activating the cash card further 
comprises the steps of: 

transmitting a cash card identification number and a point of sale 
identification number to the server using a secure channel; and 
1 5 initiating the secure channel with a secret key, wherein the secret key 

is unique for each point of sale terminal. 

72. The method of claim 71 , further comprising the steps of: 
generating a cash card secret code for each cash card based on a 

master key; and 

20 generating a point of sale secret code for each point of sale terminal 

based on the master key, 

wherein the cash card secret code is used to authorize the cash card. 

73. A method for purchasing products from a merchant over a 
network using a cash card, comprising the steps, executed in a data 

25 processing system, of: 

transmitting purchase information to a payment code window 
associated with the user, wherein the purchase information includes a 
merchant identification number; 

receiving a transaction from a user in a server, wherein the transaction 
30 is based on the received purchase information and includes a payment 
specific authentication number and a cash card identification number; 
processing the transaction; and 



WO 01/11515 PCT/US00/14603 

-38- 

transmitting an acknowledgment to a merchant computer of the 
transaction. 

74. The method of claim 73, further comprising the step of: 
transmitting the payment code window program to the user, wherein 

the code window program is used transmit payment information to the server 

75. The method of claim 73, wherein receiving a transaction from a 
user further comprises the steps of: 

creating the payment specific authentication number based on a 
personal identification number associated with the user and a cash card 
secret key associated with the cash card. 

76. The method of claim 73, wherein processing the transaction 
further includes: 

determining whether an account associated with the cash card is active 
and contains funds sufficient to purchase the product; and 

determining whether the payment specific authentication is correctly 
computed. 
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